28 - Query Multiple Elements

之前学习了8个查询单个元素的API，现在开始学习查询多个元素的API。以getAllBy开头的api，如果查找到了，则返回数组；否则报错。

所有getBy开头的API，以getAllBy开头都有：

我们现在只需要关注getAllByRole这个API，其余的可以自行学习。

创建组件Skills：

xxxxxxxxxx
17
1
// src\components\Skills\Skills.tsx
2
​
3
import type { SkillsProps } from "./Skills.types";
4
​
5
export const Skills = (props: SkillsProps) => {
6
  const { skills } = props;
7
​
8
  return (
9
    <>
10
      <ul>
11
        {skills.map((skill) => {
12
          return <li key={skill}>{skill}</li>;
13
        })}
14
      </ul>
15
    </>
16
  );
17
};

xxxxxxxxxx
5
1
// src\components\Skills\Skills.types.ts
2
​
3
export type SkillsProps = {
4
  skills: string[]
5
}

编写测试文件：

xxxxxxxxxx
20
1
// src\components\Skills\Skills.test.tsx
2
​
3
import { render, screen } from "@testing-library/react";
4
import { Skills } from "./Skills";
5
​
6
describe("Skills", () => {
7
  const skills = ["HTML", "CSS", "JavaScript"];
8
​
9
  test("renders correctly", () => {
10
    render(<Skills skills={skills} />);
11
    const listElement = screen.getByRole("list"); // ul元素的role=list
12
    expect(listElement).toBeInTheDocument();
13
  });
14
​
15
  test("renders a list of skills", () => {
16
    render(<Skills skills={skills} />);
17
    const listItemElements = screen.getAllByRole("listitem"); // li元素的role=listitem
18
    expect(listItemElements).toHaveLength(skills.length);
19
  });
20
});

测试OK。

29 - TextMatch

这是我们之前写的查询代码，这些查询API的第一个参数，看上去好像是第一个参数必须是string类型，其实不是。

第一个参数是TextMatch类型，可以是string、regex或者是一个函数。

1、当TextMatch是string类型时

2、当TextMatch是regex时

3、当TextMatch是function时

function应该按照下面这种ts类型来写

30 - queryBy

如果想要测试没有出现在DOM中的代码，该怎么做呢？

比如说我使用isLoggedIn来条件显示代码，怎么测没有出现在DOM中的代码呢？

x
1
// src\components\Skills\Skills.tsx
2
​
3
import { useState } from "react";
4
import type { SkillsProps } from "./Skills.types";
5
​
6
export const Skills = (props: SkillsProps) => {
7
  const { skills } = props;
8
  const [isLoggedIn, setIsLoggedIn] = useState(false);
9
​
10
  return (
11
    <>
12
      <ul>
13
        {skills.map((skill) => {
14
          return <li key={skill}>{skill}</li>;
15
        })}
16
      </ul>
17
      {isLoggedIn ? (
18
        <button>Start Learning</button>
19
      ) : (
20
        <button onClick={() => setIsLoggedIn(true)}>Login</button>
21
      )}
22
    </>
23
  );
24
};

此时使用getBy前缀的方法，是拿不到<button>Start Learning</button>这个DOM的，所以即使我是这样来测试（.not.toBeInTheDocument()），也会报错：

x
1
// src\components\Skills\Skills.test.tsx
2
​
3
test("Start learning button is not rendered", () => {
4
    render(<Skills skills={skills} />);
5
    const startLearningButton = screen.getByRole("button", {
6
        name: "Start learning",
7
    });
8
    expect(startLearningButton).not.toBeInTheDocument();
9
});

这时候就可以使用queryBy...或者queryAllBy...前缀开头的API，getBy...开头的API它们都有相应的。

queryBy... 最常用于测试组件中的 条件渲染（Conditional Rendering），即检查某个元素在特定条件下应该被移除。

queryAllBy... 最常用于测试列表或重复元素，以确认在某种状态下（如列表为空）页面上没有任何该类型的元素出现。

那么测试代码就可以使用queryByRole：

x
1
test("Start learning button is not rendered", () => {
2
    render(<Skills skills={skills} />);
3
    const startLearningButton = screen.queryByRole("button", {
4
        name: "Start learning",
5
    });
6
    expect(startLearningButton).not.toBeInTheDocument();
7
});

测试OK：

31 - findBy

我们之前已经学了：

当你的组件在渲染后不会立即显示某个元素，而需要等待异步操作（如 API 调用、定时器、状态更新）完成后才显示时，该怎么办？

findBy 和 findAllBy 是 React Testing Library (RTL) 中专用于 异步操作 的查询方法。

它们的作用是：在一段等待时间（默认 1000ms 或可配置）内，持续地（45ms 的间隔 内，反复执行查询）查找一个元素，直到找到它，或者超时失败。返回结果是一个 Promise。

在Skills.tsx里面，添加延时操作，0.5s后显示Start learning这个button。

使用findByRole方法：

x
1
test("Start learning button is eventually displayed", async () => {
2
    render(<Skills skills={skills} />);
3
    const startLearningButton = await screen.findByRole("button", {
4
        name: "Start learning",
5
    });
6
    expect(startLearningButton).toBeInTheDocument();
7
});

测试OK：

下面是findBy...和findAllBy...开头的API的介绍。getBy...开头的API，findBy...和findAllBy...都有。

32 - Manual Queries

虽然可以使用之前学过的JS DOM API来获取元素，但是不推荐使用这些方法来测试。还是使用RTL Queries提供的三种类型的方法。

33 - Debugging

如果测试代码里面有错误，terminal里面的信息也是很详细的。比如说我把button的内文本写错了：

terminal里面的信息给出了提示：

还有两种方法，能够帮助我们进行调试。

1、screen.debug()

作用：将当前在 jsdom 中渲染的整个 DOM 结构（或指定的元素）以易于阅读的字符串形式输出到控制台（console）。

可以看到，两处的dom树结构不一样，这是因为中间使用了promise查询。

2、logRoles方法

作用：扫描当前渲染的 DOM 结构，并将所有元素及其对应的 WAI-ARIA 角色（Role）和可访问性名称（Accessible Name）打印到控制台。

logRoles() 是 RTL 核心哲学 的完美体现：鼓励开发者通过 角色 和 名称 来查询元素。

查找正确的 Role： 当你想使用 getByRole 进行查询，但不确定一个元素到底被识别为哪个角色时（例如，一个自定义组件），logRoles() 可以告诉你准确的角色名称。

验证 Accessible Name： 确保你的交互元素（按钮、链接、输入框）具有正确的 可访问性名称。如果名称不正确，getByRole 或 getByLabelText 就会失败。

发现 ARIA 错误： 它可以帮助你发现哪些元素缺少必要的 ARIA 属性，从而改进组件的可访问性。

调试查询失败： 当 getByRole 失败时，运行 logRoles() 可以直接告诉你这个元素的可访问性名称是什么，你只需将这个名称填入 getByRole 的 name 选项即可。

引入：

x
1
import { logRoles } from "@testing-library/react";

使用：

输出：

可以看到，会输出元素对应的role属性值和Name值。

34 - Testing Playground

这个插件已经没有了，不用管了。

35 - User Interactions

测试同样需要保证用户交互符合预期。

需要使用user-event库。安装：npm i @testing-library/user-event。所有user event的API都是异步的。

虽然RTL里面有fireEvent可以模拟用户操作，但是user-event更牛逼。

36 - Pointer Interactions

这节课学习测试鼠标点击事件。在 @testing-library/user-event 中，"Pointer Interactions"（指针交互）API 涵盖了所有与 鼠标、触摸板或触摸屏 相关的操作。

这些方法旨在模拟用户与屏幕上的元素进行指向和点击的真实行为。

创建组件：

x
1
// src\components\Count\Count.tsx
2
​
3
import { useState } from "react";
4
​
5
export const Count = () => {
6
  const [count, setCount] = useState(0);
7
  return (
8
    <>
9
      <h1>{count}</h1>
10
      <button onClick={() => setCount(count + 1)}>Increment</button>
11
    </>
12
  );
13
};

编写测试文件：

xxxxxxxxxx
1
37
1
// Count.test.tsx
2
​
3
import { render, screen } from "@testing-library/react";
4
import { Count } from "./Count";
5
import userEvent from "@testing-library/user-event";
6
​
7
describe("Count", () => {
8
  test("renders correctly", () => {
9
    render(<Count />);
10
    const countElement = screen.getByRole("heading");
11
    expect(countElement).toBeInTheDocument();
12
​
13
    const incrementButton = screen.getByRole("button", {
14
      name: "Increment",
15
    });
16
    expect(incrementButton).toBeInTheDocument();
17
  });
18
​
19
  test("renders a count of 0", () => {
20
    render(<Count />);
21
    const countElement = screen.getByRole("heading");
22
    expect(countElement).toHaveTextContent("0");
23
  });
24
​
25
  test("render a count of 1 after clicking the increment button", async () => {
26
    userEvent.setup(); // 初始化userEvent
27
    render(<Count />);
28
    const incrementButton = screen.getByRole("button", {
29
      name: "Increment",
30
    });
31
    // 模拟点击事件
32
    await userEvent.click(incrementButton);
33
    const countElement = screen.getByRole("heading");
34
    expect(countElement).toHaveTextContent("1");
35
  });
36
});

测试OK：

🖱️ 核心指针交互 API

这些API经常使用。

👇 低级指针 API (用于复杂交互)

以下 API 用于模拟更底层的指针事件，通常用于测试拖放、长按等复杂或自定义的交互逻辑。这些API不经常使用。

37 - Keyboard Interactions

这节课学习键盘相关的交互API。

修改Count组件代码，添加input和button。

x
1
// src\components\Count\Count.tsx
2
​
3
import { useState } from "react";
4
​
5
export const Count = () => {
6
  const [count, setCount] = useState(0);
7
  const [amount, setAmount] = useState(0);
8
  return (
9
    <>
10
      <h1>{count}</h1>
11
      <button onClick={() => setCount(count + 1)}>Increment</button>
12
      <input
13
        type="number"
14
        name="amount"
15
        value={amount}
16
        onChange={(e) => setAmount(parseInt(e.target.value))}
17
      />
18
      <button onClick={() => setCount(amount)}>Set</button>
19
    </>
20
  );
21
};

编写键盘交互测试代码：

测试OK：

核心键盘交互API

低级指针API（用于复杂交互）

38 - Providers

接下来我们学习怎么测试Provider里面的组件，后面几节课会学习测试自定义react hooks。

我们使用mui的theme作为provider。

1、安装：npm install @mui/material @emotion/react @emotion/styled。

2、创建provider文件：

x
1
// src\providers\app-providers.tsx
2
​
3
import { CssBaseline } from "@mui/material";
4
import { ThemeProvider, createTheme } from "@mui/material/styles";
5
​
6
const theme = createTheme({
7
  palette: {
8
    mode: "dark",
9
  },
10
});
11
​
12
export const AppProviders = ({ children }: { children: React.ReactNode }) => {
13
  return (
14
    <ThemeProvider theme={theme}>
15
      <CssBaseline />
16
      {children}
17
    </ThemeProvider>
18
  );
19
};

3、创建mui-mode组件，并在App.tsx里面使用它

x
1
// App.tsx
2
​
3
import "./App.css";
4
import { AppProviders } from "./providers/app-providers";
5
import { MuiMode } from "./components/mui/mui-mode";
6
​
7
function App() {
8
  return (
9
    <AppProviders>
10
      <div className="App">
11
        <MuiMode />
12
      </div>
13
    </AppProviders>
14
  );
15
}
16
​
17
export default App;

x
1
// src\components\mui\mui-mode.tsx
2
​
3
import { Typography } from "@mui/material";
4
import { useTheme } from "@mui/material/styles";
5
​
6
export const MuiMode = () => {
7
  const theme = useTheme();
8
  return <Typography component="h1">{`${theme.palette.mode} mode`}</Typography>;
9
};

mui-mode组件的意思就是：当设置了provider的mode之后，mui-mode组件会根据provider的值，展示不同的文字。dark mode或者light mode。

4、编写测试文件

重点就是怎么编写matcher里面的值。如果写成这样.toHaveTextContent("dark mode");，会报错。

x
1
import { render, screen } from "@testing-library/react";
2
import { MuiMode } from "./mui-mode";
3
​
4
describe("MuiMode", () => {
5
  test("renders text correctly", () => {
6
    render(<MuiMode />);
7
    const headingElement = screen.getByRole("heading");
8
    expect(headingElement).toHaveTextContent("dark mode");
9
  });
10
});

查看报错信息，可以看到预期是dark mode，但是实际上是light mode。可是我明明provider里面设置的是dark啊。

这是因为在MuiMode组件里面，并没有AppProvider。我们是在App.tsx里面使用的AppProvider，所以当render(<MuiMode />)的时候，接收不到设置的provider。

解决办法：给render方法传递第二个参数，设置wrapper的值为AppProviders。这个意思是在render MuiMode组件之前，使用AppProviders包裹它。

x
1
test("renders text correctly", () => {
2
    render(<MuiMode />, {
3
        wrapper: AppProviders,
4
    });
5
    const headingElement = screen.getByRole("heading");
6
    expect(headingElement).toHaveTextContent("dark mode");
7
});

测试OK：

也许你会想，在App.tsx中，我们可能会使用到很多Providers，那里面的组件测试时都要先包裹住这些Providers吗？太复杂了吧。有没有一次性定义的方式，让我们在组件测试的时候能不用写wrapper呢？

有，下节课会讲到。

39 - Custom Render Functions

上节课我们提出了一个疑问，既然provider里面的组件都使用到了这个provider，而且provider可能有多个，那岂不是要在每一个测试用例里面写wrapper参数？

testing library提供了一个解决办法：https://testing-library.com/docs/react-testing-library/setup。

编写一个test-utils.tsx的文件，在里面封装自定义的render，这样以后使用render或其它testing-library/react的API，就可以从这个文件引入。

xxxxxxxxxx
1
16
1
// mui-mode.test.tsx
2
​
3
// 不要从 @testing-library/react 导入方法了
4
// import { render, screen } from "@testing-library/react";
5
​
6
// 要从定义好的test-utils文件里面导入
7
import { render, screen } from "../../test-utils";
8
import { MuiMode } from "./mui-mode";
9
​
10
describe("MuiMode", () => {
11
  test("renders text correctly", () => {
12
    render(<MuiMode />);
13
    const headingElement = screen.getByRole("heading");
14
    expect(headingElement).toHaveTextContent("dark mode");
15
  });
16
});

这样测试OK：

40 - Custom React Hooks

这节课学习怎么测试自定义hooks。

1、创建自定义hook

x
22
1
// src\hooks\use-counter\useCounter.types.ts
2
export type UseCounterProps = {
3
  initialCount?: number;
4
}
5
​
6
​
7
// src\hooks\use-counter\useCounter.tsx
8
​
9
import { useState } from "react";
10
import type { UseCounterProps } from "./useCounter.types";
11
​
12
export const useCounter = ({ initialCount = 0 }: UseCounterProps = {}) => {
13
  const [count, setCount] = useState(initialCount);
14
  const increment = () => setCount(count + 1);
15
  const decrement = () => setCount(count - 1);
16
  return {
17
    count,
18
    increment,
19
    decrement,
20
  };
21
};

2、创建测试文件

测试hook不能使用render，要使用renderHook方法。renderHook 的作用就是：

• 创建虚拟组件： 它在后台静默地创建一个轻量级的、功能性的 React 组件。

• 调用 Hook： 在这个虚拟组件的内部调用你要测试的自定义 Hook。

• 捕获结果： 将 Hook 的返回值（和状态）暴露出来，供你在测试中检查和操作。

核心属性：

测试代码：

x
1
// src\hooks\use-counter\useCounter.test.tsx
2
​
3
import { renderHook } from "@testing-library/react";
4
import { useCounter } from "./useCounter";
5
​
6
describe("useCounter", () => {
7
  test("should render the initial count", () => {
8
    // 使用renderHook方法来测试react hook
9
    const { result } = renderHook(useCounter);
10
    expect(result.current.count).toBe(0);
11
  });
12
​
13
  test("should accept and render the same initial count", () => {
14
    // 可以定义初始值，看输出结果是否符合
15
    const { result } = renderHook(useCounter, {
16
      initialProps: {
17
        initialCount: 10,
18
      },
19
    });
20
​
21
    expect(result.current.count).toBe(10);
22
  });
23
});

测试OK：

renderHook的initialProps参数：

41 - Act Utility

上节课学习了怎么测试一个react hook的初始值是否符合预期。这节课学习测试hook里面定义的方法。

在写测试代码时，调用hook里面的函数，需要写在act()里面进行调用，这是约定。

测试OK：

42 - Mocking Functions

这节课开始学习mock测试。使用vitest的fn方法，vi.fn()。

1、创建组件

x
1
// src\components\counter-two\counter-two.tsx
2
​
3
type CounterTwoProps = {
4
  count: number;
5
  increment: () => void;
6
  decrement: () => void;
7
};
8
​
9
export const CounterTwo = ({ count, increment, decrement }: CounterTwoProps) => {
10
  return (
11
    <>
12
      <h1>Counter Two</h1>
13
      <p>{count}</p>
14
      {increment && <button onClick={increment}>Increment</button>}
15
      {decrement && <button onClick={decrement}>Decrement</button>}
16
    </>
17
  );
18
};

可以看到，数据是以Props的形式传递过去的。

2、编写测试代码

重点是函数怎么测试，函数只写出了ts类型，但是该怎么测才是正确的方式呢？需要测这些：

• 当 increment 和 decrement 存在时，渲染对应的按钮。

• 点击按钮时，调用传入的 increment / decrement 函数。

• 当 increment 或 decrement 为 undefined 时，不渲染对应按钮。

如果以后写了组件，不知道该测什么，直接问AI。

x
34
1
// src\components\counter-two\counter-two.test.tsx
2
​
3
import { render, screen } from "@testing-library/react";
4
import { CounterTwo } from "./counter-two";
5
import userEvent from "@testing-library/user-event";
6
​
7
describe("CounterTwo", () => {
8
  test("renders correctly", () => {
9
    render(<CounterTwo count={0} />);
10
    const textElement = screen.getByText("Counter Two");
11
    expect(textElement).toBeInTheDocument();
12
  });
13
​
14
  // 这里测试函数是否被调用
15
  test("handlers are called", async () => {
16
    userEvent.setup();
17
    // 使用 vi.fn 来创建两个模拟函数，测试中只需要确认这两个函数被调用过就行了
18
    const incrementFn = vi.fn();
19
    const decrementFn = vi.fn();
20
    render(<CounterTwo count={0} increment={incrementFn} decrement={decrementFn} />);
21
    const incrementButton = screen.getByRole("button", {
22
      name: "Increment",
23
    });
24
    const decrementButton = screen.getByRole("button", {
25
      name: "Decrement",
26
    });
27
​
28
    await userEvent.click(incrementButton);
29
    await userEvent.click(decrementButton);
30
    expect(incrementFn).toHaveBeenCalledTimes(1);
31
    expect(decrementFn).toHaveBeenCalledTimes(1);
32
  });
33
});

测试OK：

43 - Mocking HTTP Requests

这节课学习mock http请求。

1、创建组件

x
1
// src\components\users\users.tsx
2
​
3
import { useEffect, useState } from "react";
4
​
5
export const Users = () => {
6
  const [users, setUsers] = useState<string[]>([]);
7
  const [error, setError] = useState<string | null>(null);
8
​
9
  useEffect(() => {
10
    fetch("https://jsonplaceholder.typicode.com/users")
11
      .then((res) => res.json())
12
      .then((data) => setUsers(data.map((user: { user: string }) => user.name)))
13
      .catch(() => setError("Error fetching users"));
14
  }, []);
15
​
16
  return (
17
    <div>
18
      <h1>Users</h1>
19
      {error && <p>{error}</p>}
20
      <ul>
21
        {users.map((user) => (
22
          <li key={user}>{user}</li>
23
        ))}
24
      </ul>
25
    </div>
26
  );
27
};

2、编写测试代码

应该测什么呢？

如果数据请求失败，就显示error信息。如果数据请求成功，就显示users信息。

那么测试里面不需要真正请求原始的接口，只需要使用mock请求接口即可。使用https://mswjs.io/提供的工具。下节课会讲到。

44 - MSW Setup

这节课我们知道了Mock Http请求需要用到msw，这节课我们来学习设置它。直接参考mswjs.io的文档：https://mswjs.io/docs/quick-start

1、安装依赖npm i msw --save-dev

2、创建请求处理函数

下节课会讲到。

3、流程级集成

这一步就是配置服务器。

x
1
// src/mock/server.ts
2
​
3
import { setupServer } from 'msw/node'
4
import { handlers } from './handlers' // 这里就是处理函数的文件
5
 
6
export const server = setupServer(...handlers)

45 - MSW Handlers

创建处理函数：

x
1
// src\mock\handlers.ts
2
​
3
import { http, HttpResponse } from 'msw'
4
​
5
export const handlers = [
6
  // 这里的接口地址和组件里面要定义成一样的
7
  http.get('https://jsonplaceholder.typicode.com/users', () => {
8
    return HttpResponse.json([
9
      {
10
        name: "Bruce Wayne"
11
      },
12
      {
13
        name: "Clark Kent"
14
      },
15
      {
16
        name: "Princess Diana"
17
      },
18
    ])
19
  }),
20
]

46 - Testing with MSW

为了能在测试的时候，告诉测试页面使用mock接口，需要在setupTests.ts里面，加上这些代码：

注意：MSW是没有管jestdom相关的测试的，所以它单独写了一个vitest.setup.ts的文件。我只需要将它的代码添加到setupTests.ts里面去就行了。

x
10
1
// src\setupTests.ts
2
​
3
import "@testing-library/jest-dom"
4
import { beforeAll, afterEach, afterAll } from 'vitest'
5
import { server } from './mock/server'
6
​
7
// 启动 MSW server
8
beforeAll(() => server.listen())
9
// 每次测试后重置 handlers（防止状态污染）
10
afterEach(() => server.resetHandlers())
11
// 测试结束后关闭
12
afterAll(() => server.close())

接下来就可以写测试代码了：

x
1
// src\components\users\users.test.tsx
2
​
3
import { render, screen } from "@testing-library/react";
4
import { Users } from "./users";
5
​
6
describe("Users", () => {
7
  test("renders correctly", () => {
8
    render(<Users />);
9
    const textElement = screen.getByText("Users");
10
    expect(textElement).toBeInTheDocument();
11
  });
12
​
13
  test("renders a list of users", async () => {
14
    render(<Users />);
15
    // 因为在全局启用了 msw server，所以会监听相应的接口请求，会返回handlers里面定义的值
16
    const users = await screen.findAllByRole("listitem");
17
    expect(users).toHaveLength(3);
18
  });
19
});

测试OK：

47 - MSW Error Handling

之前的测试，还没有覆盖接口请求error的情况，这节课来完善。

问题：怎么模拟接口请求错误的情况呢？

使用 server.use() 只在当前测试中替换某个请求的响应，其他测试依然走正常逻辑。

x
1
// 
2
​
3
import { render, screen } from "@testing-library/react";
4
import { Users } from "./users";
5
import { server } from "../../mock/server";
6
import { http, HttpResponse } from "msw";
7
​
8
describe("Users", () => {
9
  test("renders correctly", () => {
10
    render(<Users />);
11
    const textElement = screen.getByText("Users");
12
    expect(textElement).toBeInTheDocument();
13
  });
14
​
15
  test("renders a list of users", async () => {
16
    render(<Users />);
17
    const users = await screen.findAllByRole("listitem");
18
    expect(users).toHaveLength(3);
19
  });
20
​
21
  test("renders error", async () => {
22
    // 使用 server.use 来替换请求的响应
23
    server.use(
24
      http.get("https://jsonplaceholder.typicode.com/users", () => {
25
        return new HttpResponse(null, { status: 500 });
26
      })
27
    );
28
​
29
    render(<Users />);
30
    const error = await screen.findByText("Error fetching users");
31
    expect(error).toBeInTheDocument();
32
  });
33
});

测试OK：

这个替换掉的请求，会不会影响正常的请求呢？

不会，因为在superTests.ts里面，我们已经加了afterEach(() => server.resetHandlers())，这句话说明每次请求之后，会重置handlers，所以不会影响。

48 - Static Analysis Testing

静态分析测试。

不需要运行代码，就可以检查你的代码是否符合以下期望。

静态测试分析这些方面：代码可读性、持续性、错误处理、类型检查、是否符合最佳实践。总之，就是检查代码写的好不好。

主要有5种工具，其中typescript已经加到项目里面了，一直在用，所以学习剩下的四个。

49 - Eslint

eslint：“代码的语法警察 + 质量守门员”。它不运行代码，而是“读懂”代码，帮你提前发现问题。

ESLint 的 6 大核心作用

因为项目自带了eslint，所以vscode里面要安装eslint插件来帮助我们。

针对测试，可以安装npm i -D eslint-plugin-jest-dom，来帮助我们分析自己写的jest-dom相关的代码。需要同时配置eslint.config.js，使用的时候找资料即可。

50 - Prettier

prettier是格式化代码工具，可配置。

使用npm i -D --exact prettier，会安装最新稳定版本的prettier，并且锁定到精确版本号（不会用 ^ 允许小版本升级）。如果要更精准的，那么可以在后面加上具体的版本号prettier@3.3.3。

因为prettier的版本号不同，格式化的风格也会不同，这样一个团队里面的格式化效果就会有区别。

在package.json里面加一条命令：

xxxxxxxxxx
1
{
2
    "scripts": {
3
        ......
4
        "format": "prettier --ignore-path .gitignore --write \"**/*.{ts,tsx,css,scss}\""
5
    }
6
}

忽略掉.gitignore里面不上传到git的文件，然后--write自动修复并保存这些后缀名的文件。

可以使用vscode里面的prettier插件，配置format on save，这样每次保存文件的时候就会格式化，避免每次都要运行命令。

如果eslint和prettier有冲突，可以安装npm i -D eslint-config-prettier，并配置即可。

51 - Husky

Husky 是一个 Git Hooks 工具，让你可以在 git commit、git push 等 Git 操作时，自动运行脚本（比如：格式化代码、运行测试、代码检查）。

安装：npm install -D husky

初始化husky：npx husky init，自动创建.husky/pre-commit文件。

配置pre-commit脚本：

x
1
#!/bin/sh
2
. "$(dirname "$0")/_/husky.sh"
3
​
4
npm run format     # 自动格式化
5
npm run lint:fix   # 自动修复 ESLint

52 - lint-staged

上面使用husky，可以在进行git操作之前，帮助我们格式化、eslint等操作。但是husky会检查整个项目，而我们只需要它帮我们检查修改的文件，怎么办到呢？

使用lint-staged。

lint-staged是一个工具，让你在 git commit 时，只对「被修改的文件（staged files）」运行 lint、format、test 等命令。

1、安装npm install -D lint-staged。

2、在package.json里面添加配置

x
1
{
2
    ......
3
    "lint-staged": {
4
    "*.{js,jsx,ts,tsx}": [
5
      "eslint --fix",
6
      "prettier --write"
7
    ],
8
    "*.{json,css,scss}": [
9
      "prettier --write"
10
    ]
11
  }
12
}

3、修改pre-commit脚本，现在只需要运行lint-staged即可

4
1
#!/bin/sh
2
. "$(dirname "$0")/_/husky.sh"
3
​
4
npx lint-staged

4、如果想在git push之前运行测试，可以这样配置

创建 pre-push 脚本文件，运行命令npx husky add .husky/pre-push "npm run test"，编辑pre-push文件。

x
1
#!/bin/sh
2
. "$(dirname "$0")/_/husky.sh"
3
​
4
# 运行测试，使用单次运行模式，而不是监听模式
5
npm run test -- --watchAll=false

53 - Wrapping Up

section1：介绍了什么是测试？

section2：介绍了jest相关内容

section3-4：介绍了RTL相关内容

section5：怎么测试交互

section6：怎么测试provider相关内容，怎么测试hooks

section7：怎么使用mock进行测试

section8：学习静态分析测试